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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief History 



The present document is one of a series of ECMA Standards defining the interworking of services and signalUng 
protocols deployed in Corporate telecommunication Networks (CN). The series uses telecommunication concepts as 
developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as 
defined by ISO/IEC. It has been produced under ETSI work item DEN/ECMA-00195. 

The present document defines the signalling protocol interworking for call transfer supplementary services between a 
Private Integrated Services Network (PISN) and a packet-based private telecommunications network based on the 
Internet Protocol (IP). It is further assumed that the protocol for the PISN part is that defined for the Q reference point 
(QSIG) and that the protocols for the IP-based network are based on ITU-T Recommendation H.323 [10]. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document has been adopted by the ECMA General Assembly of June 2000. 
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1 Scope 



The present document specifies signalling interworking between "QSIG" and "H.323" in support of the call transfer 
supplementary services within a Corporate telecommunication Network (CN). 

"QSIG" is a signalling protocol that operates at the Q reference point between Private Integrated Services eXchanges 
(PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in ECMA-133 [2]. A 
PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in other 
ECMA Standards, in particular ECMA-143 [3] (call control in support of basic services), ECMA-165 [4] (generic 
functional protocol for the support of supplementary services) and a number of standards specifying individual 
supplementary services. ECMA- 178 [5] specifies the QSIG protocol in support of call transfer by consultation and 
ECMA-300 [6] specifies the QSIG protocol in support of single step call transfer. 

"H.323" is a set of signalling protocols for the support of voice or multimedia communication within a packet network, 
in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 
signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or 
directly. An endpoint can be a terminal or a gateway to another network. H.323 is an "umbrella" recommendation 
referring to various ITU-T recommendations, in particular Recommendations H.225.0 [8] and H.245 [9] (basic 
communication capabilities) and Recommendation H.450.1 [11] (generic functional protocol for the support of 
supplementary services). Recommendation H.450.2 [12] specifies the H.323 protocol in support of call transfer. 

NOTE: H.450.2 applies only to the 1998 version of ITU-T Recommendation H.323 [1] (also known as H.323 
version 2) and to later versions. 

Call transfer by consultation, as supported by ECMA-178 [5], is a supplementary service that enables a user (user A) to 
transform two of that user's calls (at least one of which must be answered) into a new call between the two other users in 
the two calls (users B and C). 

Single step call transfer, as supported by ECMA-300 [6], is a supplementary service that enables a user (user A) to 
transform an existing call between user A and user B into a new call between user B and user C without user A needing 
to establish a call with user C prior to transfer. 

Call transfer, as supported by H.450.2 [12], is a supplementary service that enables the served user (user A) to transform 
an existing call with a second user (user B) into a new call between user B and a third user (user C) selected by user A. 
User A may or may not have a call established with user C prior to call transfer. If a call is already established between 
user A and user C, this is known as transfer by consultation and is equivalent to call transfer as supported by 
ECMA-178 [5]. If a call is not already established between user A and user C, this is known as single step call transfer 
and is equivalent to call transfer as supported by ECMA-300 [6]. 

Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of an IP 
network, or a call originating at a user of an IP network to terminate at a user of a PISN. The present document provides 
the following additional capabilities: 

a PISN user with two calls established, at least one of which being to or from a user in an IP network, to be able 
to transform those two calls into a new call between the other two users involved; 

a PISN user with a call established to or from a user in an IP network to be able to transform that call into a new 
call between the IP network user and a third user selected by the PISN user, that third user being either in the IP 
network or in the PISN; 

a PISN user with a call established to a second PISN user to be able to transfer that call into a new call between 
the second user and a third user selected by the first user, that third user being in an IP network; 

an IP network user with two calls established, at least one of which being to or from a user in a PISN, to be able 
to transform those two calls into a new call between the other two users involved; 

an IP network user with a call established to or from a user in a PISN to be able to transform that call into a new 
call between the PISN user and a third user selected by the IP network user, that third user being either in the IP 
network or in the PISN; and 

an IP network user with a call established to a second user in the IP network to be able to transfer that call into a 
new call between the second user and a third user selected by the first user, that third user being in a PISN. 
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The present document is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG 
and an IP network employing H.323. 



2 Conformance 

In order to conform to the present document, a gateway shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 
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4 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

4.1 External definitions 

The present document uses the following terms defined in other documents: 

Call: (ECMA-307) 

Corporate telecommunication Network (CN): (ECMA-307) 

Endpoint: (ITU-T Recommendation H.323) 

IP network: (ECMA-307) 

Gatekeeper: (ITU-T Recommendation H.323) 

Private Integrated Services Network (PISN): (ECMA-307) 

Private Integrated services Network eXchange (PINX): (ECMA-133) 

Additionally the definitions in ECMA-178 [5], ECMA-300 [6] and ITU-T Recommendation H.450.2 [12] apply as 
appropriate. 

4.2 Other definitions 

4.2.1 Entity A 

In call transfer by consultation, the signalling entity at the PINX or H.323 endpoint serving the transferring user 
(user A). 

4.2.2 Entity A* 

In single step call transfer, the signalling entity at the PINX or H.323 endpoint serving the transferring user (user A). 

4.2.3 Entity B 

In call transfer by consultation, the signalling entity in the PISN or IP network associated with the call between the 
transferring user (user A) and the transferred user (user B). 

4.2.4 Entity B* 

In single step call transfer, the signalling entity in the PISN or IP network associated with the call between the 
transferring user (user A) and the transferred user (user B). 

4.2.5 Entity B' 

Signalling entity at the PINX or the H.323 endpoint serving the transferred user (user B). 

4.2.6 Entity C 

In call transfer by consultation, the signalling entity in the PISN or IP network associated with the call between the 
transferring user (user A) and the transferred-to-user (user C). 
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4.2.7 Entity C 



In single step call transfer, the signalling entity in the PISN or IP network associated with the call between the 
transferred user (user B) and the transferred-to-user (user C). 

4.2.8 Entity C 

Signalling entity at the PINX or H.323 endpoint serving the transferred-to-user (user C). 

4.2.9 Gateway 

A gateway as defined in H.323 specifically for the purpose of interworking with a network employing QSIG. 

4.2.10 LegAB 

In call transfer by consultation, the call segment that lies between entity A and entity B. 

4.2.11 LegAB* 

In single step call transfer, the call segment that lies between entity A* and entity B*. 

4.2.12 Leg AC 

In call transfer by consultation, the call segment that lies between entity A and entity C. 

4.2.13 LegBC 

In call transfer by consultation, the call segment that lies between entity B and entity C. 

4.2.14 LegBC* 

In single step call transfer, the call segment that lies between entity B* and entity C*. 

4.2.15 Leg B 

In call transfer by consultation, the call segment that lies between the entity B and entity B'. 

4.2.16 Leg B* 

In single step call transfer, the call segment that lies between entity B* and entity B'. 

4.2.17 Lege 

In call transfer by consultation, the call segment that lies between entity C and entity C. 

4.2.18 Scenario AB1 

Interworking arrangement in which entity A (PINX A) is in the PISN and entity B is in the IP network. 

4.2.19 Scenario AB*1 

Interworking arrangement in which entity A* (PINX A) is in the PISN and entity B* is in the IP network. 
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4.2.20 Scenario AB2 

Interworking arrangement in which entity A (endpoint A) is in the IP network and entity B is in the PISN. 

4.2.21 Scenario AB*2 

Interworking arrangement in which entity A* (endpoint A) is in the IP network and entity B* is in the PISN. 

4.2.22 Scenario AC1 

Interworking arrangement in which entity A (PINX A) is in the PISN and entity C is in the IP network. 

4.2.23 Scenario AC2 

Interworking arrangement in which entity A (endpoint A) is in the IP network and entity C is in the PISN. 

4.2.24 Scenario BC1 

Interworking arrangement in which entity B (PINX B) is in the PISN and entity C is in the IP network. 

4.2.25 Scenario BC*1 

Interworking arrangement in which entity B* (PINX B) is in the PISN and entity C* is in the IP network. 

4.2.26 Scenario BC2 

Interworking arrangement in which entity B is in the IP network and entity C is in the PISN. 

4.2.27 Scenario BC*2 

Interworking arrangement in which entity B* is in the IP network and entity C* is in the PISN. 

4.2.28 Scenario B1 

Interworking arrangement in which entity B (PINX B) is in the PISN and entity B' is in the IP network. 

4.2.29 Scenario B*1 

Interworking arrangement in which entity B* (PINX B) is in the PISN and entity B' is in the IP network. 

4.2.30 Scenario B2 

Interworking arrangement in which entity B (diverting endpoint or its gatekeeper) is in the IP network and entity B' is in 
the PISN. 

4.2.31 Scenario B*2 

Interworking arrangement in which entity B* (diverting endpoint or its gatekeeper) is in the IP network and entity B' is 
in the PISN. 

4.2.32 Scenario CI 

Interworking arrangement in which entity C (PINX C) is in the PISN and entity C is in the IP network. 
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4.2.33 Scenario C2 

Interworking arrangement in which entity C (endpoint C) is in the IP network and entity C is in the PISN. 



Acronyms 



APDU Application Protocol Data Unit 

CN Corporate telecommunication Network 

ICS Implementation Conformance Statement 

IP Internet Protocol 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

SS-CT Supplementary Service Call Transfer 

SS-SSCT Supplementary Service Single Step Call Transfer 



6 Service architecture 

6.1 Service architecture for invocation and operation 
6.1 .1 QSIG service arciiitecture 

QSIG supports two different call transfer services: 
transfer by consultation (ECMA-178); and 
- single step call transfer (ECMA-300). 

6.1 .1 .1 ECMA-1 78 service architecture - transfer by consultation 

ECMA-178 supports a call transfer service that starts from a situation where user A has two calls (typically one of 
which is on hold). Transfer from this situation can be performed in two ways: by join (at the PINX serving user A) or 
by rerouteing. 

A single model can be derived to accommodate both scenarios. The model involves five signalling entities as follows: 

entity A - acts on behalf of user A and co-ordinates the transfer; 

entity B - initiates the re-routed connection from the first transferred user (user B) to the other transferred user 
(user C); 

entity B' - acts on behalf of user B; 

entity C - terminates the re-routed connection from user B to user C and completes the join; and 

entity C - acts on behalf of user C. 
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This can be represented diagrammatically as shown in figure 1 . 



Leg AB 



Entity A 




Entity B 



LegB 



Entity B' 



LegBC 



Leg AC 



Entity C 



Lege 



Entity C 



Figure 1 : Generalized caii transfer model for QSIG transfer by consultation 

From this it can be seen that there are five segments or "legs" to the call: 

leg AB between entity A and entity B; 

leg AC between entity A and entity C; 

leg BC between entity B and entity C; 

leg B between entity B and entity B'; and 

leg C between entity C and entity C. 

The protocol defined in ECMA-178 [5] supports each of these five legs. 

For both transfer by join and transfer by rerouteing, entities A, B' and C are located at the PINX serving user A, user B 
and user C respectively. 

For call transfer by join, entities B and C are collocated with entity A in the PINX serving user A. This means that legs 
AB, AC and BC are all internal to that PINX, and therefore the QSIG protocols for these legs do not apply. Only the 
QSIG protocols for legs B and C apply. This is shown in figure 2. 



PINXB 



PINX A 




Entity A 



Entity B 



Entity 




PINXG 



Figure 2: Call transfer by join model for QSIG 



For call transfer by rerouteing, entity B is collocated with entity B' in the PINX serving user B, and entity C is 
collocated with entity C in the PINX serving user C. This means that legs B and C are internal to the respective PINXs, 
and therefore the QSIG protocols for these legs do not apply. Only the QSIG protocols for legs AB, AC and BC apply. 
This is shown in figure 3. 
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PINXB 



Leg AB 



PINXA 



Entity A 




Leg AC 



Entity B 


Entity B' 




Leg BC 


Entity C 


Entity C 



PINXC 



Figure 3: Call transfer by rerouteing model for QSIG 

In both cases (transfer by join and transfer by rerouteing), where a user is in another network, the role of entity A, entity 
B' or entity C is performed by the other network, the gateway PINX or the two in combination. However, from the 
QSIG point of view the role is performed by the gateway PINX. 



6.1.1.2 



ECMA-300 service architecture - single step call transfer 



ECMA-300 supports a call transfer service that starts from a situation where user A has an active call with user B and 
the call is to be transferred to user C in the case where A does not already have a call to user C. 

If user A does not provide sufficient information to enable a call to be established to user C, user B may provide 
additional information to identify user C and enable the call to be established. 

The generalized model for Single Step call Transfer is as shown in figure 4. 




Figure 4: Generalized model for QSIG Single Step Call Transfer 

Compared with the general model for transfer by consultation, the following differences exist: 
entity A* replaces entity A (although it has some common functionality); 
entity B* replaces entity B (although it has some common functionality); 
entity C* replaces entity C; 

leg AB* replaces leg AB (but differs only slightly); 
leg BC* replaces leg BC (but differs only slightly); 
leg B* replaces Leg B (but differs only slightly); and 
leg AC does not exist. 



ETSI 



15 



ETSI TS 101 907 VI. 1.1 (2001-04) 



Entities A*, B' and C are located at the PINX serving user A, user B and user C respectively. 

Entity B* may be located at any PINX between entity A* and Entity B'. 

Entity C* is always collocated with entity C in the PINX serving user C. This means that the leg between entity C* and 
entity C is internal to the PINX, and therefore the QSIG protocol for this leg does not apply. Only the protocols defined 
in ECMA-300 [6] for legs AB*, BC* and B* apply. 

Where a user is in another network, the role of entity A*, entity B' or the combined entities C*/C' is performed by the 
other network, the gateway PINX or the two in combination. However, from the QSIG point of view the role is 
performed by the gateway PINX. 

6.1 .2 H.450.2 service architecture 

H.450.2 supports two different call transfer services: 

transfer by consultation (similar to the service supported by ECMA-178); and 
single step call transfer (similar to the service supported by ECMA-300). 



6.1.2.1 



Transfer by consultation 



The model shown in figure 1 for QSIG call transfer by consultation applies also to H.450.2. Various scenarios arise, 
depending on gatekeeper involvement. A gatekeeper can act on behalf of user B and/or a gatekeeper can act on behalf 
of user C. 

If no gatekeepers are involved in the call transfer service, entity A is located at user A's endpoint, entities B and B' are 
located at user B's endpoint, and entities C and C are located at user C's endpoint. Legs AB, AC and BC are supported 
by H.450.2 signalling. This is shown in figure 5. 

Endpoint B 



Leg AB 



Endpoint A 




Leg AG 



Entity B 


Entity B' 




LegBC 


Entity 


Entity C 



Endpoint 



Figure 5: H.450.2 call transfer by consultation model - no gatekeepers involved 

If a gatekeeper is involved in call transfer on behalf of user B and another gatekeeper is involved on behalf of user C, 
entities B and C are located in the respective gatekeepers and legs AB, AC, CB, B and C are all supported by H.450.2 
signalling. This is shown in figure 6. 
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Leg AB 



Endpoint A 



Entity A 



Leg AC 



Gatekeeper B 




Entity B 



LegBC 



Entity C 



Gatekeeper C 



LegB 



Lege 



Endpoint B 



Entity B' 



Entity C 



Endpoint C 



Figure 6: H.450.2 call transfer by consultation model - gatekeepers involved 
on behalf of endpoint B and endpoint C 

Models for the cases where only entity B or only entity C is located at a gatekeeper can easily be derived. 

If the same gatekeeper acts on behalf of user B and user C, the model in figure 7 applies. In this case leg BC is internal 
to the gatekeeper and H.450.2 signalling does not apply. 
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Leg AB 
Leg AC 
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LegB^^ 
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Entity B' 
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Entity C 












Entity C 



Endpoint C 

Figure 7: H.450.2 call transfer by consultation model - single gatekeeper 
involved on behalf of endpoint B and endpoint C 

Where a user is in another network, the role of entity A, entities B and B' or entities C and C is performed by the other 
network, the gateway, or the two in combination. However, from the H.450.2 point of view the role is performed by the 

gateway. 

NOTE: The equivalent of QSIG transfer by join does not exist with H.450.2. Legs AB and AC exist in all 
scenarios (although leg BC can be hidden inside a gatekeeper). 
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6.1 .2.2 Single step call transfer 

For single step call transfer, the general model is as shown in figure 4. 

Unlike the QSIG single step call transfer supplementary service (see [13]), the H.450.2 single step call transfer 
supplementary service does not enable user B to provide additional information to identify user C if user A did not 
provide sufficient information to enable a call to be established to user C. 

Various scenarios arise, depending on gatekeeper involvement. A gatekeeper can act on behalf of user B and/or a 
gatekeeper can act on behalf of user C. This has impact on the exposure of legs B* and C*, as for transfer by 
consultation. 

If no gatekeepers are involved in single step call transfer, entity A* is located at user A's endpoint, entities B* and B' are 
located at user B's endpoint, and entities C* and C are located at user C's endpoint. Legs AB*, and BC* are supported 
by H.450.2 signalling. This is shown in figure 8. 

Endpoint B 



Leg AB* 
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Entity B* 


Entity B' 




Leg BC* 


Entity C* 


Entity C 



Endpoint C 

Figure 8: H.450.2 single step call transfer model - no gatekeepers involved 

If a gatekeeper is involved in single step call transfer on behalf of user B and another gatekeeper is involved on behalf 
of user C, entities B* and C*/C' are located in the respective gatekeepers and legs AB*, BC*, and B* are all supported 
by H.450.2 signalling. This is shown in figure 9. 



Gatekeeper B 



Endpoint B 




Gatekeeper 

Figure 9: H.450.2 single step call transfer model - gatekeepers involved 
on behalf of endpoint B and endpoint C 

Models for the cases where only entity B or only entity C is located at a gatekeeper can easily be derived. 

If the same gatekeeper acts on behalf of user B and user C, the model in figure 10 applies. In this case leg BC* is 
internal to the gatekeeper and H.450.2 signalling does not apply. 
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Endpoint B 



Endpoint A 




Figure 10: H.450.2 single step call transfer model - single gatekeeper involved 
on behalf of endpoint B and endpoint C 

In all of these cases of single step call transfer, where a user is in another network, the role of entity A*, entities B* and 
B' or entities C* and C is performed by the other network, the gateway, or the two in combination. However, from the 
H.450.2 point of view the role is performed by the gateway. 

6.1 .3 Scenarios for interworking 



6.1.3.1 



Transfer by consultation 



The models for QSIG and H.450.2 are very similar. This means that the same model is applicable to the 
inter-networking situation between an IP network and a PISN, where one or more of the users involved are served by 
the IP network and the others are served by the PISN. 

Entities A, B' and C are always located in the network of the user concerned, but there is some flexibility in the location 
of entities B and C. Interworking between H.450.2 and QSIG can occur on any of the five legs. For each of the five 
possible points of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies. 
This gives 10 scenarios in total that need to be considered: 

Scenario ABl: Entity A (PINX A) in PISN, entity B (gatekeeper B or endpoint B) in IP network; 

- Scenario AB2: Entity A (endpoint A) in IP network, entity B (PINX B) in PISN; 

- Scenario ACl: Entity A (PINX A) in PISN, entity C (gatekeeper C or endpoint C) in IP network; 

- Scenario AC2: Entity A (endpoint A) in IP network, entity C (PINX C) in PISN; 

- Scenario BC 1 ; Entity B (PINX B) in PISN, entity C (gatekeeper C or endpoint C) in IP network; 

- Scenario BC2: Entity B (gatekeeper B or endpoint B) in IP network, entity C (PINX C) in PISN; 

- Scenario Bl: Entity B (PINX B) in PISN, entity B' (endpoint B) in IP network; 

Scenario B2: Entity B (gatekeeper B or endpoint B) in IP network, entity B' (PINX B) in PISN; 

- Scenario CI: Entity C (PINX C) in PISN, entity C (endpoint C) in IP network; and 

Scenario C2: Entity C (gatekeeper C or endpoint C) in IP network, entity C (PINX C) in PISN. 

With scenarios ABl, AB2, ACl, AC2, BCl and BC2, the PISN is involved in transfer by rerouteing. Since this is only 
an optional part of ECMA-178, these scenarios will not always be available. 

It is possible for more than one scenario to apply to the same call. In particular, because of the triangular situation, 
scenarios ABl, AB2, ACl, AC2, BCl and BC2 will always occur in pairs, e.g., scenarios ABl and ACl if entity A is in 
the PISN and entities B and C are in the IP network. 

A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view 
of the IP network and an end PINX from the point of view of the PISN. Call transfer entities can be located in the 
gateway but are logically separate from the point of interworking. For example, if user B is in the PISN and users A and 
C are in the IP network, entity B could be located in the gateway on the IP network side of the interworking point, with 
entity B' in the PISN (PINX B). Logically interworking would still be taking place on leg B. 
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6.1 .3.2 Single step call transfer 



The models for QSIG and H.450.2 are very similar. This means that the same model is applicable to the 
inter-networking situation between an IP network and a PISN, where one or more of the users involved are served by 
the IP network and the others are served by the PISN. 

Entities A*, B' C* and C are always located in the network of the user concerned, but there is some flexibility in the 
location of entity B*. Interworking between H.450.2 and QSIG can occur on any of legs AB*, BC* and B*. For each of 
the three points of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies. 
This gives six scenarios in total that need to be considered: 

Scenario AB*1; Entity A* (PINX A) in PISN, entity B* (gatekeeper B* or endpoint B*) in IP network; 

- Scenario AB*2: Entity A* (endpoint A) in IP network, entity B* (PINX B) in PISN; 

Scenario BC*1: Entity B* (PINX B) in PISN, entity C* (gatekeeper C* or endpoint C*) in IP network; 

Scenario BC*2: Entity B* (gatekeeper B* or endpoint B*) in IP network, combined entities C*/C' (PINX C) in 
PISN; 

- Scenario B* 1 : Entity B* (PINX B) in PISN, entity B' (endpoint B) in IP network; 

Scenario B*2: Entity B* (gatekeeper B* or endpoint B*) in IP network, entity B' (PINX B) in PISN. 

It is possible for more than one scenario to apply to the same call e.g., scenarios BC*1 and B*l if entity B* is in the 
PISN and entities B' and C* are in the IP network. 

A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view 
of the IP network and an end PINX from the point of view of the PISN. Single step call transfer entities can be located 
in the gateway but are logically separate from the point of interworking. For example, if user B is in the PISN and users 
A and C are in the IP network, entity B* could be located in the gateway on the IP network side of the interworking 
point, with entity B' in the PISN (PINX B). Logically interworking would still be taking place on leg B*. 
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6.1 .4 Determination of tine location of entities wiien interworking 



6.1.4.1 



Transfer by consultation 



Entities A, B' and C are always located in the network of the user concerned. The locations of entities B and C are 
determined as follows. 

If user A and therefore entity A are in the QSIG network at PINX A and PINX A implements only transfer by join or 
chooses to perform transfer by join, entities B and C will be located at PINX A. Interworking will occur on leg B and/or 
leg C, depending on the location of users B and C. This is shown in figure 11. 
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Figure 11 : Interworking - transfer by join in a PISN 

If user A and therefore entity A are in the QSIG network at PINX A and PINX A performs transfer by rerouteing, if 
user B is in the IP network the gateway between user A's network and user B's network can choose, on receipt of a 
transfer request from PINX A, whether to provide entity B (in which case interworking occurs on leg B) or to instruct 
the IP network to provide entity B (in which case interworking occurs on leg AB). 

Similarly, if user C is in the IP network the gateway between user A's network and user B's network can choose, on 
receipt of a transfer identify request from PINX A, whether to provide entity C (in which case interworking occurs on 
leg C) or to instruct the IP network to provide entity C (in which case interworking occurs on leg AC). 

Figure 12 and figure 13 show the two cases where the two gateways make the same decision. If the two gateways make 
different decisions, interworking will also occur on leg BC. The case where entity B is in the PISN and entity C is in the 
IP network is shown in figure 14. The reverse case is not shown. 



ETSI 



21 



ETSI TS 101 907 VI. 1.1 (2001-04) 



PINXA 



Entity A 



PISN 



IP network 



II G/W 



l/W 

(Scenario 
AB1) 



Leg AB II 

II 

Leg AC II 



l/W 

(Scenario 
AC1) 



II G/W 



Endpoint B 



Entity B 


Entity B' 




Leg BO 


Entity 


Entity 0' 



Endpoint 



Figure 12: Interworking - transfer by rerouteing between PINX A and 
endpoints B and C in tlie IP network 
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Figure 13: Interworking - transfer by rerouteing between PINX A and 

two gateways 
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Figure 14: Interworking - transfer by rerouteing -between PINX A, entity B in 
a gateway and entity C in tlie IP network 

If user A and therefore entity A are in the IP network at endpoint A, if user B is in the PISN the gateway between user 
A's network and user B's network can choose, on receipt of a transfer request from endpoint A, whether to provide 
entity B (in which case interworking occurs on leg B) or to instruct the PISN to provide entity B (in which case 
interworking occurs on leg AB). The latter requires support for transfer by rerouteing in the PISN. 

Similarly, if user C is in the PISN the gateway between user A's network and user C's network can choose, on receipt of 
a transfer identify request from endpoint A, whether to provide entity C (in which case interworking occurs on leg C) or 
to instruct the PISN to provide entity C (in which case interworking occurs on leg AC). The latter requires support for 
transfer by rerouteing in the PISN. If the two gateways make different decisions, interworking will also occur on 
leg BC. 

Figure 15 and figure 16 show the two cases where the two gateways make the same decision. If the two gateways make 
different decisions (not shown), interworking will also occur on leg BC. 
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Figure 15: Interworking - transfer by rerouteing between endpoint A in tlie 
IP network and PINXs B and C 
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Figure 16: Interworking - transfer by rerouteing between endpoint A in the 
IP network and two gateways 

In cases where a gateway can choose whether to provide entity B or entity C functionahty, the gateway's decision is an 
implementation matter. This can, but need not, take account of the user C or user B respectively. The behaviour of 
entity B or entity C, if provided at the gateway, is outside the scope of the present document and is assumed to be in 
accordance with the requirements of ECMA-178 (when entity A is in the PISN) or in accordance with the requirements 
of H.450.2 (when entity A is in the IP network). 
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6.1 .4.2 Single step call transfer 

Entities A*, B' C* and C are always located in the network of the user concerned. The location of entity B* is 
determined as follows. 

If user A and therefore entity A* are in the QSIG network at PINX A entity B* may be located at PINX A. 
Interworking will occur on leg B* and/or leg BC*, depending on the location of users B and C. 

If user B is in the IP network, the gateway between user As network and user B's network can choose, on receipt of a 
transfer request from PINX A, whether to provide entity B* (in which case interworking occurs on leg B*) or to instruct 
the IP network to provide entity B* (in which case interworking occurs on leg AB*). 

Figure 17 shows the case where entity B* is provided by the gateway. Figure 18 shows the case where entity B* is 
provided by the IP network. 
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Figure 17: Interworking - single step call transfer in a PISN 
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Figure 18: Interworking - single step call transfer between PINX A and 
endpoints B and C in the IP network 



ETSI 



25 



ETSI TS 101 907 VI. 1.1 (2001-04) 



Also, in the case where entity B* is provided by the IP network and user C is in the PISN, interworking will also occur 
on leg BC*. This case is not shown. 

If user A and therefore entity A* are in the IP network at endpoint A, if user B is in the PISN the gateway between user 
A's network and user B's network can choose, on receipt of a transfer request from endpoint A, whether to provide 
entity B* (in which case interworking occurs on leg B*) or to instruct the PISN to provide entity B* (in which case 
interworking occurs on leg AB*). These are shown in figure 19 and figure 20. 
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Figure 19: Interworking - single step call transfer between endpoint A in 
the IP network and two gateways 
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Figure 20: Interworking - single step call transfer between endpoint A in the 
IP network and PINXs B and C 
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Also, in the case where entity B* is provided by the PISN and user C is in the IP network, interworking will also occur 
on leg BC*. This case is not shown. 

In cases where a gateway can choose whether to provide entity B* functionality, the gateway's decision is an 
implementation matter. This can, but need not, take account of the location of user C. The behaviour of entity B*, if 
provided at the gateway, is outside the scope of the present document and is assumed to be in accordance with the 
requirements of ECMA-300 (when entity A* is in the PISN) or in accordance with the requirements of H.450.2 (when 
entity A* is in the IP network). 

6.2 Service architecture for activation, deactivation and 
interrogation 

6.2.1 QSIG service architecture 

6.2.1 .1 ECMA-1 78 service architecture 

Not applicable. 

6.2.1 .2 ECMA-300 service architecture 

Not applicable. 

6.2.2 H.450.2 service architecture 

Not applicable. 

6.2.3 Scenarios for interworking 

Not applicable. 

7 Protocol interworking - General requirements 

Protocol interworking between H.323 and QSIG for call transfer supplementary services shall be in accordance with 
ECMA-307, as modified by the requirements of clauses 8 and 9. 

When transmitting an APDU in one protocol as a result of receiving the corresponding APDU in the other protocol, the 
mapping of elements in the received APDU to corresponding elements in the transmitted APDU shall be in accordance 
with ECMA-307. 

8 Protocol interworking - Messages and APDUs 

In the rules specified below for the different scenarios, the following shall apply: 

1) If the required action is to transmit a QSIG or H.323 FACILITY message but the call state does not permit a 
FACILITY message to be sent at that time, the action to be taken is an implementation matter. 

2) If the required action is to include an APDU in a transmitted QSIG or H.323 message conditional upon that 
message being transmitted and that message is not to be transmitted (owing to basic call interworking 
considerations), the action to be taken is an implementation matter. 
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8.1 



Scenario AB1 



A gateway that supports scenario ABl shall behave in accordance with the rules of table 1, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A, or receipt 
of an H.323 message from entity B. 

Table 1 : Message and APDU handling requirements for scenario AB1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferlnitiate invoke APDU wliile tlie QSIG 
call is in the active state. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferlnitiate invoke APDU if the H.323 
call state permits. 


2 


Receipt of an H.323 RELEASE CQIVIPLETE message 
containing an H.323 callTransferlnitiate return result 
APDU in response to an H.323 callTransferlnitiate 
invoke APDU. 


If a QSIG DISCQNNECT message is to be 
transmitted, include in the QSIG DISCQNNECT 
message a QSIG callTransferlnitiate return result 
APDU. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferlnitiate return error APDU in 
response to an H.323 callTransferlnitiate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferlnitiate return error APDU if the 
QSIG call state permits. 



8.2 



Scenario AB2 



A gateway that supports scenario AB2 shall behave in accordance with the rules of table 2, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity A, or 
receipt of a QSIG message from entity B. 

Table 2: Message and APDU handling requirements for scenario AB2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferlnitiate invoke APDU while the H.323 
call is in the active state. 


If the callldentity element in the H.323 
callTransferlnitiate invoke APDU is not empty, 
transmit a QSIG FACILITY message containing a 
QSIG callTransferlnitiate invoke APDU if the QSIG 
call state permits. 

If the callldentity element in the H.323 
callTransferlnitiate invoke APDU is empty, refer to the 
rules in clause 8.12, or reject the request if single 
step call transfer is not supported. 


2 


Receipt of a QSIG DISCQNNECT message containing 
a QSIG callTransferlnitiate return result APDU in 
response to a QSIG callTransferlnitiate invoke APDU. 


If an H.323 RELEASE CQMPLETE message is to be 
transmitted, include in the H.323 RELEASE 
CQMPLETE message an H.323 callTransferlnitiate 
return result APDU. 


3 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferlnitiate return error APDU in response 
to a QSIG callTransferlnitiate invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferlnitiate return error APDU if the 
H.323 call state permits. 
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8.3 



Scenario AC1 



A gateway that supports scenario ACl shall behave in accordance with the rules of table 3, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A, or receipt 
of an H.323 message from entity C. 

Table 3: Message and APDU handling requirements for scenario AC1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferldentify invoke APDU wliile tlie QSIG 
call is either in the call received state or in the active 
state. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferldentify invoke APDU if the H.323 
call state permits. 


2 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferldentify return result APDU in 
response to an H.323 callTransferldentify invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferldentify return result APDU if the 
QSIG call state permits. 


3 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferAbandon invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferAbandon invoke APDU if the H.323 
call state permits. 


4 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferldentify return error APDU in 
response to an H.323 callTransferldentify invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferldentify return error APDU if the 
QSIG call state permits. 



8.4 



Scenario AC2 



A gateway that supports scenario AC2 shall behave in accordance with the rules of table 4, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity A, or 
receipt of a QSIG message from entity C. 

Table 4: Message and APDU handling requirements for scenario AC2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferldentify invoke APDU while the H.323 
call is either in the call received state or in the active 
state. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferldentify invoke APDU if the QSIG 
call state permits. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferldentify return result APDU in 
response to a QSIG callTransferldentify invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferldentify return result APDU if the 
H.323 call state permits. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferAbandon invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferAbandon invoke APDU if the QSIG 
call state permits. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferldentify return error APDU in 
response to a QSIG callTransferldentify invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferldentify return error APDU if the 
H.323 call state permits. 
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8.5 



Scenario BC1 



A gateway that supports scenario BCl shall behave in accordance with the rules of table 5, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B, or receipt 
of an H.323 message from entity C. 

Table 5: Message and APDU handling requirements for scenario BC1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG SETUP message containing a QSIG 
callTransferSetup invoke APDU. 


If an H.323 SETUP message is to be transmitted, 
include in the H.323 SETUP message an H.323 
callTransferSetup invoke APDU. If the QSIG SETUP 
message also contains a QSIG callTransferUpdate 
invoke APDU, include an H.323 callTransferUpdate 
invoke APDU in the H.323 SETUP message. 


2 


Receipt of an H.323 ALERTING message containing an 
H.323 callTransferSetup return result APDU in 
response to an H.323 callTransferSetup invoke APDU. 


If a QSIG ALERTING message is to be transmitted, 
include in the QSIG ALERTING message a QSIG 
callTransferSetup return result APDU. If the H.323 
ALERTING message also contains an H.323 
callTransferUpdate invoke APDU, include a QSIG 
callTransferUpdate invoke APDU in the QSIG 
ALERTING message. 


3 


Receipt of an H.323 GQNNECT message containing an 
H.323 callTransferSetup return result APDU in 
response to an H.323 callTransferSetup invoke APDU. 


If a QSIG CQNNECT message is to be transmitted, 
include in the QSIG CQNNECT message a QSIG 
callTransferSetup return result APDU. If the H.323 
CQNNECT message also contains an H.323 
callTransferUpdate invoke APDU, include a QSIG 
callTransferUpdate invoke APDU in the QSIG 
CQNNECT message. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


6 


Receipt of an H.323 RELEASE CQMPLETE message 
containing an H.323 callTransferSetup return error 
APDU in response to an H.323 callTransferSetup 
invoke APDU. 


If a QSIG DISCQNNECT message is to be 
transmitted, include in the QSIG DISCQNNECT 
message a QSIG callTransferSetup return error 
APDU. 
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8.6 



Scenario BC2 



A gateway that supports scenario BC2 shall behave in accordance with the rules of table 6, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity B, or 
receipt of a QSIG message from entity C. 

Table 6: Message and APDU handling requirements for scenario BC2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 SETUP message containing an 
H.323 callTransferSetup invoke APDU. 


If the callldentity element in the H.323 
callTransferSetup invoke APDU is not empty, then if a 
QSIG SETUP message is to be transmitted, include in 
the QSIG SETUP message a QSIG callTransferSetup 
invoke APDU. If the H.323 SETUP message also 
contains an H.323 callTransferUpdate invoke APDU, 
include a QSIG callTransferUpdate invoke APDU in 
the QSIG SETUP message. 
If the callldentity element in the H.323 
callTransferSetup invoke APDU is empty, refer to the 
rules in clause 8.14, or reject the request if single step 
call transfer is not supported. 


2 


Receipt of a QSIG ALERTING message containing a 
QSIG callTransferSetup return result APDU in response 
to a QSIG callTransferSetup invoke APDU. 


If an H.323 ALERTING message is to be transmitted, 
include in the H.323 ALERTING message an H.323 
callTransferSetup return result APDU. If the QSIG 
ALERTING message also contains a QSIG 
callTransferUpdate invoke APDU, include an H.323 
callTransferUpdate invoke APDU in the H.323 
ALERTING message. 


3 


Receipt of a QSIG GQNNEGT message containing a 
QSIG callTransferSetup return result APDU in response 
to a QSIG callTransferSetup invoke APDU. 


If an H.323 CQNNECT message is to be transmitted, 
include in the H.323 CQNNECT message an H.323 
callTransferSetup return result APDU. If the QSIG 
CQNNECT message also contains a QSIG 
callTransferUpdate invoke APDU, include an H.323 
callTransferUpdate invoke APDU in the H.323 
CQNNECT message. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


6 


Receipt of a QSIG call clearing message containing a 
QSIG callTransferSetup return error APDU in response 
to a QSIG callTransferSetup invoke APDU. 


If an H.323 RELEASE CQMPLETE message is to be 
transmitted, include in the H.323 RELEASE 
CQMPLETE message an H.323 callTransferSetup 
return error APDU. 
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8.7 Scenario B1 

A gateway that supports scenario Bl shall behave in accordance with the rules of table 7, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B, or receipt 
of an H.323 message from entity B'. 

Table 7: Message and APDU handling requirements for scenario Bl 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferComplete invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferComplete invoke APDU if the H.323 
call state permits. If the QSIG FACILITY message 
also contains a QSIG callTransferUpdate APDU, then 
include an H.323 callTransferUpdate invoke APDU in 
the H.323 FACILITY message. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU if the H.323 
call state permits. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU if the QSIG 
call state permits. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


6 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferActive invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferActive invoke APDU if the H.323 
call state permits. 



8.8 



Scenario B2 



A gateway that supports scenario B2 shall behave in accordance with the rules of table 8, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B', or receipt 
of an H.323 message from entity B. 

Table 8: Message and APDU handling requirements for scenario B2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferComplete invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferComplete invoke APDU if the QSIG 
call state permits. If the H.323 FACILITY message 
also contains an H.323 callTransferUpdate APDU, 
then include a QSIG callTransferUpdate invoke APDU 
in the QSIG FACILITY message. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU if the H.323 
call state permits. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU if the QSIG 
call state permits. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


6 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferActive invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferActive invoke APDU if the H.323 
call state permits. 
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8.9 



Scenario C1 



A gateway that supports scenario CI shall behave in accordance with the rules of table 9, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity C, or receipt 
of an H.323 message from entity C. 

Table 9: Message and APDU handling requirements for scenario C1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferComplete invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferComplete invoke APDU if the 
H.323 call state permits. If the QSIG FACILITY 
message also contains a QSIG callTransferUpdate 
APDU, then include an H.323 callTransferUpdate 
invoke APDU in the H.323 FACILITY message. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU if the H.323 
call state permits. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU if the QSIG 
call state permits. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 



8.10 Scenario C2 

A gateway that supports scenario C2 shall behave in accordance with the rules of table 10, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity C, or receipt 
of an H.323 message from entity C. 

Table 10: Message and APDU handling requirements for scenario C2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferComplete invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferComplete invoke APDU if the QSIG 
call state permits. If the H.323 FACILITY message 
also contains an H.323 callTransferUpdate APDU, 
then include a QSIG callTransferUpdate invoke APDU 
in the QSIG FACILITY message. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU if the H.323 
call state permits. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU if the QSIG 
call state permits. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 
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8.11 Scenario AB*1 

A gateway that supports scenario AB* 1 shall behave in accordance with the rules of table 1 1 , by carrying out the 
required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity A*, 
or receipt of an H.323 message from entity B*. 

Table 11 : Message and APDU handling requirements for scenario AB*1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG ssctlnitiate invoke APDU wliile tine QSIG call is in 
the active state. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferlnitiate invoke APDU if the H.323 
call state permits. 


2 


Receipt of an H.323 RELEASE GQMPLETE message 
containing an H.323 callTransferlnitiate return result 
APDU in response to an H.323 callTransferlnitiate 
invoke APDU. 


If a QSIG DISCQNNECT message is to be 
transmitted, include in the QSIG DISCQNNECT 
message a QSIG ssctlnitiate return result APDU. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferlnitiate return error APDU in 
response to an H.323 callTransferlnitiate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG ssctlnitiate return error APDU if the QSIG call 
state permits. 



8.12 Scenario AB*2 

A gateway that supports scenario AB*2 shall behave in accordance with the rules of table 12, by carrying out the 
required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity 
A*, or receipt of a QSIG message from entity B*. 

Table 12: Message and APDU handling requirements for scenario AB*2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferlnitiate invoke APDU while the H.323 
call is in the active state. 


If the callldentity element in the H.323 
callTransferlnitiate invoke APDU is empty, transmit a 
QSIG FACILITY message containing a QSIG 
ssctlnitiate invoke APDU if the QSIG call state 
permits. 

If callldentity element in the H.323 callTransferlnitiate 
invoke APDU is not empty, refer to the rules in 
clause 8.2, or reject the request if call transfer by 
consultation is not supported. 


2 


Receipt of a QSIG DISCQNNECT message containing 
a QSIG ssctlnitiate return result APDU in response to a 
QSIG ssctlnitiate invoke APDU. 


If an H.323 RELEASE CQMPLETE message is to be 
transmitted, include in the H.323 RELEASE 
CQMPLETE message an H.323 callTransferlnitiate 
return result APDU. 


3 


Receipt of a QSIG FACILITY message containing a 
QSIG ssctlnitiate return error APDU in response to a 
QSIG ssctlnitiate invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferlnitiate return error APDU if the 
H.323 call state permits. 
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8.13 Scenario BC*1 

A gateway that supports scenario BC*1 shall behave in accordance with the rules of table 13, by carrying out the 
required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B*, 
or receipt of an H.323 message from entity C*. 

Table 13: Message and APDU handling requirements for scenario BC*1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG SETUP message containing a QSIG 
ssctSetup invoke APDU. 


If an H.323 SETUP message is to be transmitted, 
include in the H.323 SETUP message an H.323 
callTransferSetup invoke APDU. 


2 


Receipt of an H.323 ALERTING message containing an 
H.323 callTransferSetup return result APDU in 
response to an H.323 callTransferSetup invoke APDU. 


Discard the H.323 callTransferSetup return result 
APDU. If the H.323 ALERTING message contains an 
H.323 callTransferUpdate invoke APDU, then if a 
QSIG ALERTING message is to be transmitted, 
include in the QSIG ALERTING message a QSIG 
callTransferUpdate invoke APDU. 


3 


Receipt of an H.323 GQNNECT message containing an 
H.323 callTransferSetup return result APDU in 
response to an H.323 callTransferSetup invoke APDU. 


Discard the H.323 callTransferSetup return result 
APDU. If the H.323 CONNECT message contains an 
H.323 callTransferUpdate invoke APDU, then if a 
QSIG CONNECT message is to be transmitted, 
include in the QSIG CONNECT message a QSIG 
callTransferUpdate invoke APDU. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


6 


Receipt of an H.323 RELEASE CQMPLETE message 
containing an H.323 callTransferSetup return error 
APDU in response to an H.323 callTransferSetup 
invoke APDU. 


Discard the H.323 callTransferSetup return error 
APDU. 
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8.14 Scenario BC*2 

A gateway that supports scenario BC*2 shall behave in accordance with the rules of table 14, by carrying out the 
required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity 
B*, or receipt of a QSIG message from entity C*. 

Table 14: Message and APDU handling requirements for scenario BC*2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 SETUP message containing an 
H.323 callTransferSetup invoke APDU. 


If the callldentity element in the H.323 
callTransferSetup invoke APDU is empty, then if a 
QSIG SETUP message is to be transmitted, include in 
the QSIG SETUP message a QSIG ssctSetup invoke 
APDU. 

If callldentity element in the H.323 callTransferSetup 
invoke APDU is not empty, refer to the rules in 
clause 8.6, or reject the request if call transfer by 
consultation is not supported. 


2 


Receipt of a QSIG ALERTING message in response to 
a QSIG ssctSetup invoke APDU. 


If an H.323 ALERTING message is to be transmitted, 
include in the H.323 ALERTING message an H.323 
callTransferSetup return result APDU. If the QSIG 
ALERTING message contains a QSIG 
callTransferUpdate invoke APDU, include an H.323 
callTransferUpdate invoke APDU in the H.323 
ALERTING message. 


3 


Receipt of a QSIG GQNNECT message in response to 
a QSIG ssctSetup invoke APDU. 


If an H.323 CQNNECT message is to be transmitted 
and an H.323 callTransferSetup return result APDU 
has not already been included in an H.323 ALERTING 
message, then include in the H.323 CQNNECT 
message an H.323 callTransferSetup return result 
APDU. If the QSIG CQNNECT message contains a 
QSIG callTransferUpdate invoke APDU, include an 
H.323 callTransferUpdate invoke APDU in the H.323 
CQNNECT message. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


6 


Receipt of a QSIG call clearing message in response to 
a QSIG ssctSetup invoke APDU. 


If an H.323 RELEASE CQMPLETE message is to be 
transmitted, include in the H.323 RELEASE 
CQIVIPLETE message an H.323 callTransferSetup 
return error APDU. 
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8.15 Scenario B*1 

A gateway that supports scenario B* 1 shall behave in accordance with the rules of table 15, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B*, or 
receipt of an H.323 message from entity B'. 

Table 15: Message and APDU handling requirements for scenario B*1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferComplete invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferComplete invoke APDU if the H.323 
call state permits. If the QSIG FACILITY message 
also contains a QSIG callTransferUpdate APDU, then 
include an H.323 callTransferUpdate invoke APDU in 
the H.323 FACILITY message. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG ssctPostDial invoke APDU. 


Discard the QSIG ssctPostDial invoke APDU. If 
further APDUs are present, then subject to rules 3, 5 
and 7, transmit an H.323 FACILITY message if the 
H.323 call state permits. 


3 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU if the H.323 
call state permits. 


4 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU if the QSIG 
call state permits. 


5 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


6 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


7 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferActive invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferActive invoke APDU if the H.323 
call state permits. 
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8.16 Scenario B*2 

A gateway that supports scenario B*2 shall behave in accordance with the rules of table 16, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity B*, or 
receipt of an H.323 message from entity B'. 

Table 16: Message and APDU handling requirements for scenario B*2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferComplete invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferComplete invoke APDU if the QSIG 
call state permits. If the H.323 FACILITY message 
also contains an H.323 callTransferUpdate APDU, 
then include a QSIG callTransferUpdate invoke APDU 
in the QSIG FACILITY message. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU if the H.323 
call state permits. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferUpdate invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferUpdate invoke APDU if the QSIG 
call state permits. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU if the H.323 
call state permits. 


5 


Receipt of an H.323 FACILITY message containing an 
H.323 subaddressTransfer invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG subaddressTransfer invoke APDU if the QSIG 
call state permits. 


6 


Receipt of an H.323 FACILITY message containing an 
H.323 callTransferActive invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callTransferActive invoke APDU if the H.323 
call state permits. 



9 Protocol interworking - Content of APDUs 

This clause contains the requirements for the mapping of elements that are not covered by the general requirements in 
clause 7. 

Rules are provided only for elements that are mandatory in at least one of the protocols. Optional elements may be 
discarded if received. 

9.1 APDU content mapping from QSIG to H.323 

9.1 .1 QSIG ssctlnitiate invoke APDU mapping to H.323 callTransferlnitiate 
invoke APDU 

A gateway that supports scenario AB*1, when transmitting an H.323 callTransferlnitiate invoke APDU as a result of 
receiving a QSIG ssctlnitiate invoke APDU, shall map elements in accordance with table 17. 

Table 17: QSIG ssctlnitiate Invoke APDU mapping to H.323 callTransferlnitiate Invoke APDU 



QSIG element name 

"(M)" denotes mandatory 

element 


H.323 element name 

"(M)" denotes mandatory 

element 


Mapping requirement 


N/A 


call Identity (IVI) 


Encode as empty (size 0) to denote invocation of 
single step call transfer. 


transferredAddress (IVI) 


N/A 


Discard. 


awaitConnect (M) 


N/A 


Discard. 
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9.1 .2 QSIG ssctSetup invoke APDU mapping to H.323 callTransferSetup 
invoke APDU 

A gateway that supports scenario BC*1, when transmitting an H.323 callTransferSetup invoke APDU as a result of 
receiving a QSIG ssctSetup invoke APDU, shall map elements in accordance with table 18. 

Table 18: QSIG ssctSetup invoke APDU mapping to H.323 callTransferSetup invoke APDU 



QSIG element name 

"(M)" denotes mandatory 

element 


H.323 element name 

"(M)" denotes mandatory 

element 


Mapping requirement 


N/A 


call Identity (M) 


Encode as empty (size 0). 



9.2 APDU content mapping from H.323 to QSIG 

9.2.1 H.323 callTransferlnitiate invoke APDU mapping to QSIG ssctlnitiate 
invoke APDU 

A gateway that supports scenario AB*2, when transmitting a QSIG ssctlnitiate invoke APDU as a result of receiving an 
H.323 callTransferlnitiate invoke APDU, shall map elements in accordance with table 19. 

Table 19: H.323 callTransferlnitiate invoke APDU mapping to QSIG ssctlnitiate invoke APDU 



H.323 element name 

"(M)" denotes mandatory 

element 


QSIG element name 

"(Wl)" denotes mandatory 

element 


Mapping requirement 


call Identity (M) 


N/A 


Discard. 


N/A 


transferredAddress (M) 


The availability of the information to be included in 
this element will depend on implementation. 
Include the information if available or include the 
indication "notAvailableDueTolnterworking" if the 
information is not available. 


N/A 


awaitConnect 


Encode with the value set to FALSE, i.e. release the 
original call on receipt of the ALERTING message. 



9.2.2 H.323 callTransferSetup invoke APDU mapping to QSIG ssctSetup 
invoke APDU 

A gateway that supports scenario BC*2, when transmitting a QSIG ssctSetup invoke APDU as a result of receiving an 
H.323 callTransferSetup invoke APDU, shall map elements in accordance with table 20. 

Table 20: H.323 callTransferSetup invoke APDU mapping to QSIG ssctSetup invoke APDU 



H.323 element name 

"(M)" denotes mandatory 

element 


QSIG element name 

"(M)" denotes mandatory 

element 


Mapping requirement 


callldentity (M) 


N/A 


Discard. 



ETSI 



39 ETSI TS 101 907 VI. 1.1 (2001-04) 



Annex A (normative): 

Implementation Conformance Statement (ICS) proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

- by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, 
e.g. through oversight; 

- by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
Standard's ICS proforma; 

- by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICS; 

- by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into clauses each containing a group of individual items. Each 
item is identified by an item reference, the description of the item (question to be answered), and the reference(s) to the 
clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

I irrelevant or out-of-scope - this capability is outside the scope of the standard to which this ICS 

proforma applies and is not subject to conformance testing in this context; 
M mandatory (the capability is required for conformance to the standard); 

N/A not applicable - in the given context, it is impossible to use the capability; no answer in the 

support column is required; 
O optional (the capability is not required for conformance to the standard, but if the capability is 

implemented it is required to conform to the specification in the present 

document); 
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0.<n qualified optional - in this case, <n> is an integer that identifies a unique group of related optional 

items; if no additional qualification is indicated, the support of at least one of the 
optional items is required for conformance to the present document; otherwise, 
the qualification and logic of the selection among the optional items is defined 
below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 

Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see A.2.4) is used after a clause heading or table title, and its predicate is false, no answer is 
required for the whole clause or table, respectively. 

A.2.2 Additional Information 

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and may be 
included in items of Exception Information. 



A.2.3 Exception Information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an Exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 

A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

"Prerequisite line" 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not required 
to be completed if the predicate is false. 

"Qualification" 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 
description of the status "qualified optional" in A.2.1. 

"Comments" 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 
separately (without using this box). 
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A.3 Identification of the Implementation 



A.3.1 Implementation Identification 



Supplier (see note 1) 




Contact point for queries about the ICS 
(see note 1) 




Implementation Name(s) and Version(s) 
(see notes land 2) 




Other information necessary for full identification 
- e.g., name(s) and version(s) for machines and/or 
operating systems; System name(s) 




NOTE 1 : Only the first three items are required for all implementations; other information may be completed as 

appropriate in meeting the requirement for full identification. 
NOTE 2: The terms Name and Version should be interpreted appropriately to correspond with a suppliers 

terminology (e.g. Type, Series, Model). 



A.3. 2 Specification for which this ICS applies 



Title 


Corporate telecommunication networks - Signalling 
interworking between QSIG and H.323 - Generic functional 
protocol for the support of supplementary services 


Version 


1.0 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required ? 


No[ ] Yes[ ] 

(The answer Yes means that the implementation does not 
conform to the present document) (see note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a 
separate sheet of paper: 
"Nature of non-conformance (if applicable):" 
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A.4 Major capabilities 



Table A.1 : Major capabilities 



Item 


Question: 
Does the implementation...? 


Conditions for status 


Status 


Reference 


Support 


MC1 


support transfer by consultation 




Q.1 




[ ]Yes [ ]No 


MC2 


support single step call transfer 




Q.1 




[ ]Yes [ ]No 


MC3 


support QSIG transfer by join 


MC1 


M 


ECMA-178 


[]Yes 


MC4 


support QSIG transfer by rerouteing 


MC1 


Q 


ECMA-178 


[ ]Yes [ ]No 


MC5 


support QSIG single step call 
transfer 


MC2 


M 


ECMA-300- 


[]Yes 


MC6 


support H.450.2 transfer by 
consultation 


MC1 


M 


H.450.2 


[]Yes 


MC7 


support H.450.2 Single Step call 
transfer 


MC2 


M 


H.450.2 


[]Yes 


MC8 


support provision of entity B for 
handling transfer by rerouteing 
requests received from the PISN 


MC4 


Q 


6.1.4.1 


[ ]Yes [ ]No 


MC9 


support provision of entity C for 
handling transfer by rerouteing 
identify requests from the PISN 


MC4 


O 


6.1.4.1 


[ ]Yes [ ]No 


MC10 


support provision of entity B for 
handling transfer by consultation 
requests received from the IP 
network 


MC6 AND MC4 
MC6 AND NQT MC4 


Q 
M 


6.1.4.1 


[ ]Yes [ ]No 
[]Yes 


MC11 


support provision of entity C for 
handling transfer by consultation 
requests received from the IP 
network 


MC6 AND MC4 
MC6 AND NQT MC4 


Q 

M 


6.1.4.1 


[ ]Yes [ ]No 
[]Yes 


MC12 


support provision of entity B* for 
handling single step call transfer 
requests received from the PISN 


MC2 


Q 


6.1.4.2 


[ ]Yes [ ]No 


MCI 3 


support provision of entity C* for 
handling single step call transfer 
requests from the PISN 


MC2 


Q 


6.1.4.2 


[ ]Yes [ ]No 


MC14 


support provision of entity B* for 
handling single step call transfer 
requests received from the IP 
network 


MC2 


O 


6.1.4.2 


[ ]Yes [ ]No 


MC15 


support provision of entity C* for 
handling single step call transfer call 
establishment requests received 
from the IP network 


MC2 


Q 


6.1.4.2 


[ ]Yes [ ]No 


MC16 


support scenario AB1 


MC4 AND MC8 
MC4 AND NQT MC8 


Q 

M 


6.1.3.1 


[ ]Yes [ ]No 
[]Yes 


MC17 


support scenario AB2 


MC4ANDMC10 
MC4ANDNQTMC10 


Q 

M 


6.1.3.1 


[ ]Yes [ ]No 
[]Yes 


MCI 8 


support scenario AC1 


MC4 AND MC9 
MC4 AND NQT MC9 


Q 

M 


6.1.3.1 


[ ]Yes [ ]No 
[]Yes 


MC19 


support scenario AC2 


MC4 AND MC1 1 
MC4 AND NQT MC1 1 


Q 

M 


6.1.3.1 


[ ]Yes [ ]No 
[]Yes 


MC20 


support scenario BC1 


MC4 


M 


6.1.3.1 


[]Yes 


MC21 


support scenario BC2 


MC4 


M 


6.1.3.1 


[]Yes 


MC22 


support scenario B1 


MC1 


M 


6.1.3.1 


[]Yes 


MC23 


support scenario B2 


MC1 


M 


6.1.3.1 


[]Yes 


MC24 


support scenario C1 


MC1 


M 


6.1.3.1 


[]Yes 


MC25 


support scenario C2 


MC1 


M 


6.1.3.1 


[]Yes 


MC26 


support scenario AB*1 


MC2ANDMC12 
MC2ANDNQTMC12 


Q 

M 


6.1.3.2 


[ ]Yes [ ]No 
[]Yes 


MC27 


support scenario AB*2 


MC2ANDMC14 
MC2ANDNQTMC14 


Q 

M 


6.1.3.2 


[ ]Yes [ ]No 
[]Yes 


MC28 


support scenario BC*1 


MC2ANDMC13 
MC2ANDNQTMC13 


Q 

M 


6.1.3.2 


[ ]Yes [ ]No 
[]Yes 
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Item 


Question: 
Does the implementation...? 


Conditions for status 


Status 


Reference 


Support 


MC29 


support scenario BC*2 


MC2ANDMC15 
MC2ANDNOTMC15 




M 


6.1.3.2 


[ ]Yes [ ]No 
[]Yes 


MC30 


support scenario B*1 


MC2 


M 


6.1.3.2 


[]Yes 


MC31 


support scenario B*2 


MC2 


M 


6.1.3.2 


[]Yes 


Comments: 



A. 5 General requirements 

Table A.2: General requirements for protocol interworking 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


GR1 


perform protocol interworking in accordance 
witli ECMA-307 




M 


7 


[]Yes 


Comments: 





A.6 Message and APDU handling 

A.6.1 Message and APDU handling for scenario AB1 

Table A.3: Message and APDU handling for scenario AB1 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MAB1 1 


beliave in accordance witli rule 1 for scenario 
AB1 


MCI 6 


M 


8.1 


[]Yes 


MAB1 2 


behave in accordance with rule 2 for scenario 
AB1 


MCI 6 


M 


8.1 


[]Yes 


MAB1 3 


behave in accordance with rule 3 for scenario 
AB1 


MCI 6 


M 


8.1 


[]Yes 


Comments: 



A.6. 2 Message and APDU handling for scenario AB2 

Table A.4: IVIessage and APDU handling for scenario AB2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MAB2 1 


behave in accordance with rule 1 for scenario 
AB2 


MCI 7 


M 


8.2 


[]Yes 


MAB2 2 


behave in accordance with rule 2 for scenario 
AB2 


MCI 7 


M 


8.2 


[]Yes 


MAB2 3 


behave in accordance with rule 3 for scenario 
AB2 


MCI 7 


M 


8.2 


[]Yes 


Comments: 
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A.6.3 Message and APDU handling for scenario AC1 

Table A.5: Message and APDU handling for scenario AC1 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MAC1 1 


behave in accordance with rule 1 for scenario 
AC1 


MC18 


M 


8.3 


[]Yes 


MAC1 2 


behave in accordance with rule 2 for scenario 
AC1 


MC18 


M 


8.3 


[]Yes 


MAC1 3 


behave in accordance with rule 3 for scenario 
AC1 


MC18 


M 


8.3 


[]Yes 


MAC1 4 


behave in accordance with rule 4 for scenario 
AC1 


MC18 


M 


8.3 


[]Yes 


Comments: 



A.6.4 IVIessage and APDU handling for scenario AC2 

Table A.6: IVIessage and APDU handling for scenario AC2 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MAC2 1 


behave in accordance with rule 1 for scenario 
AC2 


MC19 


M 


8.4 


[]Yes 


MAC2 2 


behave in accordance with rule 2 for scenario 
AC2 


MC19 


M 


8.4 


[]Yes 


MAC2 3 


behave in accordance with rule 3 for scenario 
AC2 


MC19 


M 


8.4 


[]Yes 


MAC2 4 


behave in accordance with rule 4 for scenario 
AC2 


MC19 


M 


8.4 


[]Yes 


Comments: 



A.6. 5 IVIessage and APDU handling for scenario BC1 

Table A.7: IVIessage and APDU handling for scenario BC1 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MBC1 1 


behave in accordance with rule 1 for 
scenario BC1 


MC20 


M 


8.5 


[]Yes 


MBC1 2 


behave in accordance with rule 2 for 
scenario BC1 


MC20 


M 


8.5 


[]Yes 


MBC1 3 


behave in accordance with rule 3 for 
scenario BC1 


MC20 


M 


8.5 


[]Yes 


MBC1 4 


behave in accordance with rule 4 for 
scenario BC1 


MC20 


M 


8.5 


[]Yes 


MBC1 5 


behave in accordance with rule 5 for 
scenario BC1 


MC20 


M 


8.5 


[]Yes 


MBC1 6 


Behave in accordance with rule 6 for 
scenario BC1 


MC20 


M 


8.4 


[]Yes 


Comments: 
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A.6.6 Message and APDU handling for scenario BC2 

Table A.8: Message and APDU handling for scenario BC2 



Item 


Question: 
Does the Implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MBC2 1 


behave in accordance with rule 1 for 
scenario BC2 


MC21 


M 


8.6 


[]Yes 


MBC2 2 


behave in accordance with rule 2 for 
scenario BC2 


MC21 


M 


8.6 


[]Yes 


MBC2 3 


behave in accordance with rule 3 for 
scenario BC2 


MC21 


M 


8.6 


[]Yes 


MBC2 4 


behave in accordance with rule 4 for 
scenario BC2 


MC21 


M 


8.6 


[]Yes 


MBC2 5 


behave in accordance with rule 5 for 
scenario BC2 


MC21 


M 


8.6 


[]Yes 


MBC2 6 


behave in accordance with rule 6 for 
scenario BC2 


MC21 


M 


8.6 


[]Yes 


Comments: 



A.6.7 IVIessage and APDU handling for scenario B1 

Table A.9: Message and APDU handling for scenario B1 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MB1 1 


behave in accordance with rule 1 for 
scenario B1 


MC22 


M 


8.7 


[]Yes 


MB1 2 


behave in accordance with rule 2 for 
scenario B1 


MC22 


M 


8.7 


[]Yes 


MB1 3 


behave in accordance with rule 3 for 
scenario B1 


MC22 


M 


8.7 


[]Yes 


MB1 4 


behave in accordance with rule 4 for 
scenario B1 


MC22 


M 


8.7 


[]Yes 


MB1 5 


behave in accordance with rule 5 for 
scenario B1 


MC22 


M 


8.7 


[]Yes 


MB1 6 


behave in accordance with rule 6 for 
scenario B1 


MC22 


M 


8.7 


[]Yes 


Comments: 
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A.6.8 Message and APDU handling for scenario B2 

Table A.10: Message and APDU handling for scenario B2 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MB2 1 


behave in accordance with rule 1 for 
scenario B2 


MC23 


M 


8.8 


[]Yes 


MB2 2 


behave in accordance with rule 2 for 
scenario B2 


MC23 


M 


8.8 


[]Yes 


MB2 3 


behave in accordance with rule 3 for 
scenario B2 


MC23 


M 


8.8 


[]Yes 


MB2 4 


behave in accordance with rule 4 for 
scenario B2 


MC23 


M 


8.8 


[]Yes 


MB2 5 


behave in accordance with rule 5 for 
scenario B2 


MC23 


M 


8.8 


[]Yes 


MB2 6 


behave in accordance with rule 6 for 
scenario B2 


MC23 


M 


8.8 


[]Yes 


Comments: 



A.6.9 IVIessage and APDU handling for scenario C1 

Table A.11 : Message and APDU handling for scenario C1 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MC1 1 


behave in accordance with rule 1 for 
scenario C1 


MC24 


M 


8.9 


[]Yes 


MC1 2 


behave in accordance with rule 2 for 
scenario C1 


MC24 


M 


8.9 


[]Yes 


MC1 3 


behave in accordance with rule 3 for 
scenario C1 


MC24 


M 


8.9 


[]Yes 


MC1 4 


behave in accordance with rule 4 for 
scenario C1 


MC24 


M 


8.9 


[]Yes 


MCI 5 


behave in accordance with rule 5 for 
scenario C1 


MC24 


M 


8.9 


[]Yes 


Comments: 



A.6.1 IVIessage and APDU handling for scenario C2 

Table A.12: Message and APDU handling for scenario C2 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MC2 1 


behave in accordance with rule 1 for 
scenario C2 


MC25 


M 


8.10 


[]Yes 


MC2 2 


behave in accordance with rule 2 for 
scenario C2 


MC25 


M 


8.10 


[]Yes 


MC2 3 


behave in accordance with rule 3 for 
scenario C2 


MC25 


M 


8.10 


[]Yes 


MC2 4 


behave in accordance with rule 4 for 
scenario C2 


MC25 


M 


8.10 


[]Yes 


MC2 5 


behave in accordance with rule 5 for 
scenario C2 


MC25 


M 


8.10 


[]Yes 


Comments: 
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A.6.1 1 Message and APDU handling for scenario AB*1 

Table A.13: Message and APDU handling for scenario AB*1 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MAB*1 1 


behave in accordance with rule 1 for scenario 
AB*1 


MC26 


M 


8.11 


[]Yes 


MAB*1 2 


behave in accordance with rule 2 for scenario 
AB*1 


MC26 


M 


8.11 


[]Yes 


MAB*1 3 


behave in accordance with rule 3 for scenario 
AB*1 


MC26 


M 


8.11 


[]Yes 


Comments: 



A.6.1 2 IVIessage and APDU handling for scenario AB*2 

Table A.14: IVIessage and APDU handling for scenario AB*2 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MAB*2 1 


behave in accordance with rule 1 for scenario 
AB*2 


MC27 


M 


8.12 


[]Yes 


MAB*2 2 


behave in accordance with rule 2 for scenario 
AB*2 


MC27 


M 


8.12 


[]Yes 


MAB*2 3 


behave in accordance with rule 3 for scenario 
AB*2 


MC27 


M 


8.12 


[]Yes 


Comments: 



A.6.1 3 IVIessage and APDU handling for scenario BC*1 

Table A.15: IVIessage and APDU handling for scenario BC*1 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MBC*1 1 


behave in accordance with rule 1 for 
scenario BC*1 


MC28 


M 


8.13 


[]Yes 


MBC*1 2 


behave in accordance with rule 2 for 
scenario BC*1 


MC28 


M 


8.13 


[]Yes 


MBC*1 3 


behave in accordance with rule 3 for 
scenario BC*1 


MC28 


M 


8.13 


[]Yes 


MBC*1 4 


behave in accordance with rule 4 for 
scenario BC*1 


MC28 


M 


8.13 


[]Yes 


MBC*1 5 


behave in accordance with rule 5 for 
scenario BC*1 


MC28 


M 


8.13 


[]Yes 


MBC*1 6 


behave in accordance with rule 6 for 
scenario BC*1 


MC28 


M 


8.13 


[]Yes 


Comments: 
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A.6.14 Message and APDU handling for scenario BC*2 

Table A.16: Message and APDU handling for scenario BC*2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MBC*2 1 


behave in accordance with rule 1 for scenario 
BC*2 


MC29 


M 


8.14 


[]Yes 


MBC*2 2 


behave in accordance with rule 2 for scenario 
BC*2 


MC29 


M 


8.14 


[]Yes 


MBC*2 3 


behave in accordance with rule 3 for scenario 
BC*2 


MC29 


M 


8.14 


[]Yes 


MBC*2 4 


behave in accordance with rule 4 for scenario 
BC*2 


MC29 


M 


8.14 


[]Yes 


MBC*2 5 


behave in accordance with rule 5 for scenario 
BC*2 


MC29 


M 


8.14 


[]Yes 


MBC*2 6 


behave in accordance with rule 6 for scenario 
BC*2 


MC29 


M 


8.14 


[]Yes 


Comments: 



A.6.1 5 IVIessage and APDU handling for scenario B*1 

Table A.17: IVIessage and APDU handling for scenario B*1 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MB*1 1 


behave in accordance with rule 1 for 
scenario B*1 


MC30 


M 


8.15 


[]Yes 


MB*1 2 


behave in accordance with rule 2 for 
scenario B*1 


MC30 


M 


8.15 


[]Yes 


MB*1 3 


behave in accordance with rule 3 for 
scenario B*1 


MC30 


M 


8.15 


[]Yes 


MB*1 4 


behave in accordance with rule 4 for 
scenario B*1 


MC30 


M 


8.15 


[]Yes 


MB*1 5 


behave in accordance with rule 5 for 
scenario B*1 


MC30 


M 


8.15 


[]Yes 


MB*1 6 


behave in accordance with rule 6 for 
scenario B*1 


MC30 


M 


8.15 


[]Yes 


MB*1 7 


behave in accordance with rule 7 for 
scenario B*1 


MC30 


M 


8.15 


[]Yes 


Comments: 
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A.6.1 6 Message and APDU handling for scenario B*2 

Table A.18: Message and APDU handling for scenario B*2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MB*2 1 


behave in accordance with rule 1 for 
scenario B*2 


MC31 


M 


8.16 


[]Yes 


MB*2 2 


behave in accordance with rule 2 for 
scenario B*2 


MC31 


M 


8.16 


[]Yes 


MB*2 3 


behave in accordance with rule 3 for 
scenario B*2 


MC31 


M 


8.16 


[]Yes 


MB*2 4 


behave in accordance with rule 4 for 
scenario B*2 


MC31 


M 


8.16 


[]Yes 


MB*2 5 


behave in accordance with rule 5 for 
scenario B*2 


MC31 


M 


8.16 


[]Yes 


MB*2 6 


behave in accordance with rule 6 for 
scenario B*2 


MC31 


M 


8.16 


[]Yes 


Comments: 





A.7 APDU content mapping 



Table A.19: APDU content mapping 



Item 


Question: 
Does tlie implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MAPI 


behave in accordance with mapping from 
QSIG ssctlnitiate invoke APDUs to H.323 
callTransferlnitiate invoke APDUs 


MC26 


M 


9.1.1 


[]Yes 


MAP2 


behave in accordance with mapping from 
QSIG ssctSetup invoke APDUs to H.323 
callTransferSetup invoke APDUs 


MC28 


M 


9.1.2 


[]Yes 


MAP3 


behave in accordance with mapping from 
H.323 callTransferlnitiate invoke APDUs to 
QSIG ssctlnitiate invoke APDUs 


MC27 


M 


9.1.3 


[]Yes 


MAP4 


behave in accordance with mapping from 
H.323 callTransferSetup invoke APDUs to 
QSIG ssctSetup invoke APDUs 


MC29 


M 


9.1.4 


[]Yes 


Comments: 
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